home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 2 / Apprentice-Release2.iso / Source Code / Libraries / Graphic Elements 2 / ReadMe < prev   
Encoding:
Text File  |  1994-12-03  |  5.3 KB  |  105 lines  |  [TEXT/MPS ]
  1. GRAPHIC ELEMENTS
  2.  
  3. Graphic Elements is a very general, high-performance, framework-
  4. independent graphics presentation system. It offers graphic performance 
  5. comparable to that of a "sprite animation" system. At the same time, it 
  6. affords a very flexible mechanism for defining what a graphic is and does. 
  7. Anything that can be drawn on the screen can be a Graphic Element.
  8.  
  9. The Macintosh version of Graphic Elements is compatible with any Macintosh
  10. having a 68020 (or better) processor running 32-bit QuickDraw. It is
  11. not guaranteed to be compatible with system software versions prior to
  12. System 7.
  13.  
  14. Within these limitations, the Graphic Elements system is completely "legal".
  15. Any normal Macintosh window can contain a Graphic Elements "world". The
  16. code contains no "funny stuff" which may break under some future Macintosh
  17. system release.
  18.  
  19. DESIGN PHILOSOPHY
  20.  
  21. In writing the Graphic Elements system, I had four primary objectives.
  22. First, I wanted to provide the most general paradigm possible for programming 
  23. interactive graphics software. Second, I wanted to create an application 
  24. program interface for interactive graphics which will not "break", regardless 
  25. of changes in the underlying graphic engine or even in the type of computer
  26. which hosts this engine. Third, I wanted to give the application programmer
  27. a high degree of flexibility in defining "a graphic". Finally, I wanted
  28. to allow maximum reusability of graphics code. The Graphic Elements
  29. system accomplishes these objectives in the following manner:
  30.  
  31. From the viewpoint of the application programmer, a Graphic Element is
  32. an independent software object which knows how to image itself on
  33. demand into an offscreen workspace. Each Graphic Element may optionally
  34. have ways of reacting to 1) the passage of time, 2) contact with
  35. another Graphic Element, and 3) the user's actions. These methods will
  36. be called automatically by the Graphic Elements system, as required. In
  37. addition, the application program can act on Graphic Elements explicitly
  38. at any time.
  39.  
  40. This provides a great degree of separation between the "main line" of
  41. a program's code and its graphics code. After initialization, the 
  42. application (or the view or pane object, if a class library is being used) 
  43. needs only two calls to the Graphic Elements system to run a window full 
  44. of animated graphics.
  45.  
  46. This simplification is feasible because the Graphic Elements system allows
  47. any graphic to be defined as a Graphic Element. In order to do this,
  48. the application need only define a function which will draw the element
  49. into its current rectangle in an offscreen graphics workspace provided
  50. by the Graphic Elements system.
  51.  
  52. The Graphic Elements approach leads to a style of programming in which
  53. elements, or associated groups of elements, are defined in individual
  54. "scene" modules containing all the routines used to initialize and
  55. run the elements in the "scene". Such scenes can easily be moved from
  56. one program to another by simply including them in the new program
  57. and calling their initialization routines.
  58.  
  59. DESIGN LIMITATIONS
  60.  
  61. In order to maximize versatility and generality, Graphic Elements
  62. uses a "double-buffered" drawing system, in which the "scene" is
  63. first assembled in an offscreen workspace, then copied to the screen.
  64. By its nature, such a system imposes a cost in memory (requiring an
  65. offscreen area the same size as the onscreen "world") and in time
  66. (due to the requirement for copying from offscreen to onscreen).
  67.  
  68. The significance of the time cost, in a given situation, depends on
  69. the processor speed, the video-display hardware, the required frame-
  70. generation rate, and the area of the screen which must be updated for
  71. each frame. As a rough indication, animating 32 graphics, each 32X32
  72. pixels, on each frame, the current version of Graphic Elements can
  73. generate 31 frames per second on a Quadra 800, and 8 fps on a IIsi.
  74.  
  75. THE FUTURE OF GRAPHIC ELEMENTS
  76.  
  77. I designed the Graphic Elements system according to my vision of the
  78. future of interactive-graphics programming. In doing so, I implicitly
  79. accepted the speed disadvantage and memory cost of doing things in a very 
  80. general way. I am convinced that these costs are bearable, even in
  81. the current generation of machines. With the advent of the PowerPC and
  82. other RISC-based machines, they will become insignificant.
  83.  
  84. The generality obtained by accepting these costs pays off in other, more 
  85. important ways. The same Graphic Elements "scene" source can already be 
  86. compiled under MPW C or C++, Think C 6.0, and Symantec C++. The compiled 
  87. code can be utilized from a normal application or from one based on the MacApp 
  88. or TCL class libraries. A scene module can be "adopted" into another
  89. application program by including its header file, linking it in, and
  90. calling its initialization routine.
  91.  
  92. I have no corporate sponsor, and I have exhausted my available resources
  93. in creating the present version of Graphic Elements. However, the
  94. underlying architecture of Graphic Elements is designed to be portable,
  95. not only across application-development environments, but across platforms
  96. as well. If anybody who reads this has the means and/or ability to adapt
  97. the Graphic Elements system to other platforms such as Windows or X, I
  98. would like to hear from you.
  99.  
  100.                     --Al Evans--
  101.                       al@crucible.powertools.com
  102.                       CompuServe: 72167,2253
  103.                       Mail: Powertools
  104.                           1206 Karen Ave.
  105.                         Austin, TX 78757